The development of modern software typically requires significant effort on the part of developers, engineers, and/or computer scientists. Throughout the development process, the software assets needed to create the software, e.g., source code files, continually evolve. It is not unusual for more than one developer to work on the same file, or set of files, concurrently. This requires that different versions of the same software assets be made available and tracked throughout the development process.
The different versions of software under development typically are managed by some sort of file management system. While some file management systems provide additional software development functions, such as compiling and other programming language specific functions, others simply manage files and are not tailored to any one type of development platform or environment.
One example of a file management system is Subversion. Subversion is a free, open-source, version control system capable of managing files and directories. In general, a file management system such as Subversion maintains a software repository which includes a tree of data similar to a directory structure. The tree also includes files used by the file management system to track changes to the tree, whether modifications to existing files, the addition of new files, the deletion of files, or changes to the directory structure itself. The file management system allows a developer to access older versions of any software assets maintained in the software repository.
The file management system can track many different versions of the tree. Subversion, for example, typically maintains a primary copy, or original version of the tree, called the trunk. From the trunk, branches can be created. Each branch begins as a copy of some part of the tree and, once created, has its own history. That is, each branch created from the tree represents an independent and parallel development effort. Different versions, called revisions, of branches can also be created. For example, a branch of the tree can be created for each of a plurality of different development teams. Those teams can create different revisions of the branch as development efforts progress.
In this sense, a file management system such as Subversion provides for a hierarchy of attributes, e.g., branches, revisions, or the like, for tracking changes to the tree over time. Each version of the software can be thought of as a snapshot of the software, or tree, at a given point in time as indicated by the branch and revision attributes. Eventually, the different versions of the software are merged together to create the final software product.
In a file management system, one way to obtain a particular branch or revision is simply to request a fresh copy. Requesting a fresh copy is a relatively straightforward process, but can be slow in cases where the branch or revision is large. An alternative to requesting a fresh copy is to “update” an existing copy. Typically, updating a copy is much faster than obtaining a fresh copy. When updating a copy, files can be added, deleted, and/or replaced as needed so that the copy is transformed into an exact replica of the requested copy. Generally, a client builds a temporary transaction tree that mirrors the state of the working copy. The software repository then compares that transaction tree with the revision tree of the requested revision. Information that informs the client as to the changes that are needed to transform the working copy into a replica of the desired revision tree is provided to the client. The time savings attained through updating, as opposed to obtaining a fresh copy, can be dramatic. For example, in cases where the copy to be updated and the desired copy are similar, e.g., where most of the files are identical, updating can be tens or possibly thousands of times faster than obtaining a fresh copy.
While under development, software is frequently tested. A testing farm formed of one or more computer systems is often used for testing the software. Each computer system of the testing farm (farm machine) can execute code for subjecting a particular version of the software to one or more tests. The use of a testing farm allows the software to be subjected to different tests concurrently, thereby significantly decreasing the total amount of time needed for testing.
Typically, the testing farm is implemented such that each farm machine can access a “share”, i.e., a centralized data store made available through a network connection. This share can hold the “ingredients” needed to run each test. The ingredients for a test can include, but are not limited to, the code needed to execute the test, files used by the test, input data, and expected results for the test. In the context of circuit design, for example, files needed by the test can include software-based circuit descriptions. Input data can include input signals and/or vectors. Expected output for the test can include timing information, expected signal outputs, and the like.
Typically, farm machines obtain ingredients by simply accessing the ingredients needed for a given test directly from the share. Unfortunately, this approach does not scale well with farm size. In cases where the share is heavily loaded, adding farm machines can actually diminish, rather than increase, throughput of the testing farm. Accordingly, the number of computers in a testing farm can significantly limit the effectiveness of that testing farm. In other words, the amount of time needed to download the test ingredients can counter any efficiencies gained through use of the testing farm.
Another way of making test ingredients available to farm machines is to copy test ingredients from the share to local storage of each respective farm machine before starting a given test. Once the test ingredients are stored locally, testing can begin. Again, the share is a bottleneck. Because the volume of test ingredients can be very large, a significant amount of time is needed to create a copy of the test ingredients on each farm machine.
It would be beneficial to provide a technique for testing software using testing farms that addresses the limitations described above.